The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run multiple virtual machines on a single host platform. This makes better use the capacity of the hardware, while still ensuring that each user enjoys the features of a “complete,” isolated computer.
General virtualized computer system: As is well known in the field of computer science, a virtual machine (VM) is a software abstraction—a “virtualization”—of an actual physical computer system. FIG. 1 illustrates, in part, the general configuration of a virtual machine 200, which is installed as a “guest” on a “host” hardware platform 100.
As FIG. 1 shows, the hardware platform 100 includes one or more processors (CPU's) 110, system memory 130, and a storage device, which will typically be a disk 140. The system memory will typically be some form of high-speed RAM, whereas the disk (one or more) will typically be a non-volatile, mass storage device. The hardware 100 will also include other conventional mechanisms such as a memory management unit MMU 150, various registers 160, and any conventional network connection device 170 (such as a network adapter or network interface card—“NIC”) for transfer of data between the various components of the system and a network 700, which may be any known public or proprietary local or wide-area network such as the Internet, an internal enterprise network, etc.
Each VM 200 will typically include at least one virtual CPU 210, a virtual disk 240, a virtual system memory 230, a guest operating system (which may simply be a copy of a conventional operating system) 220, and various virtual devices 230, in which case the guest operating system (“guest OS”) will include corresponding drivers 224. All of the components of the VM may be implemented in software using known techniques to emulate the corresponding components of an actual computer.
If the VM is properly designed, then it will not be apparent to the user that any applications 260 running within the VM are running indirectly, that is, via the guest OS and virtual processor. Applications 260 running within the VM will act just as they would if run on a “real” computer, except for a decrease in running speed that will be noticeable only in exceptionally time-critical applications. Executable files will be accessed by the guest OS from the virtual disk or virtual memory, which will simply be portions of the actual physical disk or memory allocated to that VM. Once an application is installed within the VM, the guest OS retrieves files from the virtual disk just as if they had been pre-stored as the result of a conventional installation of the application. The design and operation of virtual machines is well known in the field of computer science.
Some interface is usually required between a VM and the underlying host platform (in particular, the CPU), which is responsible for actually executing VM-issued instructions and transferring data to and from the actual memory and storage devices. A common term for this interface is a “virtual machine monitor” (VMM), shown as component 300. A VMM is usually a thin piece of software that runs directly on top of a host, or directly on the hardware, and virtualizes all the resources of the machine. Among other components, the VMM therefore usually includes device emulators 330, which may constitute the virtual devices (230) that the VM 200 addresses. The interface exported to the VM is then the same as the hardware interface of the machine, so that the guest OS cannot determine the presence of the VMM. The VMM also usually tracks and either forwards (to some form of operating system) or itself schedules and handles all requests by its VM for machine resources, as well as various faults and interrupts.
Although the VM (and thus the user of applications running in the VM) cannot usually detect the presence of the VMM, the VMM and the VM may be viewed as together forming a single virtual computer. They are shown in FIG. 1 as separate components for the sake of clarity.
Virtual and physical memory: As in most modern computers, the address space of the memory 130 is partitioned into pages (for example, in the Intel x86 architecture) or regions (for example, Intel IA-64 architecture). Applications then address the memory 130 using virtual addresses (VAs), which include virtual page numbers (VPNs). The VAs are then mapped to physical addresses (PAs) that are used to address the physical memory 130. (VAs and PAs have a common offset from a base address, so that only the VPN needs to be converted into a corresponding PPN.) The concepts of VPNs and PPNs, as well as the way in which the different page numbering schemes are implemented and used, are described in many standard texts, such as “Computer Organization and Design: The Hardware/Software Interface,” by David A. Patterson and John L. Hennessy, Morgan Kaufmann Publishers, Inc., San Francisco, Calif., 1994, pp. 579-603 (chapter 7.4 “Virtual Memory”). Similar mappings are used in region-based architectures or, indeed, in any architecture where relocatability is possible.
An extra level of addressing indirection is typically implemented in virtualized systems in that a VPN issued by an application 260 in the VM 200 is remapped twice in order to determine which page of the hardware memory is intended. The first mapping is provided by a mapping module within the guest OS 202, which translates the guest VPN (GVPN) into a corresponding guest PPN (GPPN) in the conventional manner. The guest OS therefore “believes” that it is directly addressing the actual hardware memory, but in fact it is not.
Of course, a valid address to the actual hardware memory must ultimately be generated. A memory management module 350 in the VMM 300 therefore performs the second mapping by taking the GPPN issued by the guest OS 220 and mapping it to a hardware (or “machine”) page number PPN that can be used to address the hardware memory 130. This GPPN-to-PPN mapping is typically done in the main system-level software layer (such as the kernel 600 described below), depending on the implementation: From the perspective of the guest OS, the GVPN and GPPN might be virtual and physical page numbers just as they would be if the guest OS were the only OS in the system. From the perspective of the system software, however, the GPPN is a page number that is then mapped into the physical memory space of the hardware memory as a PPN.
System software configurations in virtualized systems: In some systems, such as the Workstation product of VMware, Inc., of Palo Alto, Calif., the VMM is co-resident at system level with a host operating system. Both the VMM and the host OS can independently modify the state of the host processor, but the VMM calls into the host OS via a driver and a dedicated user-level application to have the host OS perform certain I/O operations of behalf of the VM. The virtual computer in this configuration is thus fully hosted in that it runs on an existing host hardware platform and together with an existing host OS.
In other implementations, a dedicated kernel takes the place of and performs the conventional functions of the host OS, and virtual computers run on the kernel. FIG. 1 illustrates a kernel 600 that serves as the system software for several VM/VMM pairs 200/300, . . . , 200n/300n. Compared with a system in which VMMs run directly on the hardware platform, use of a kernel offers greater modularity and facilitates provision of services that extend across multiple VMs (for example, for resource management). Compared with the hosted deployment, a kernel may offer greater performance because it can be co-developed with the VMM and be optimized for the characteristics of a workload consisting of VMMs. The ESX Server product of VMware, Inc., has such a configuration.
A kernel-based virtualization system of the type illustrated in FIG. 1 is described in U.S. patent application Ser. No. 09/877,378 (“Computer Configuration for Resource Management in Systems Including a Virtual Machine”), which is incorporated here by reference. The main components of this system and aspects of their interaction are, however, outlined below.
At a boot-up time, an existing operating system 420 may be at system level and the kernel 600 may not yet even be operational within the system. In such case, one of the functions of the OS 420 may be to make it possible to load the kernel 600, after which the kernel runs on the native hardware and manages system resources. In effect, the kernel, once loaded, displaces the OS 420. Thus, the kernel 600 may be viewed either as displacing the OS 420 from the system level and taking this place itself, or as residing at a “sub-system level.” When interposed between the OS 420 and the hardware 100, the kernel 600 essentially turns the OS 420 into an “application,” which has access to system resources only when allowed by the kernel 600. The kernel then schedules the OS 420 as if it were any other component that needs to use system resources.
The OS 420 may also be included to allow applications unrelated to virtualization to run; for example, a system administrator may need such applications to monitor the hardware 100 or to perform other administrative routines. The OS 420 may thus be viewed as a “console” OS (COS). In this case, the kernel 600 preferably also provides a remote procedure call (RPC) mechanism 614 to enable communication between, for example, the VMM 300 and any applications 800 installed to run on the COS 420.
Worlds: The kernel 600 handles not only the various VMM/VMs, but also any other applications running on the kernel, as well as the COS 420 and even the hardware CPU(s) 110, as entities that can be separately scheduled. In this disclosure, each schedulable entity is referred to as a “world,” which contains a thread of control, an address space, machine memory, and handles to the various device objects that it is accessing. Worlds, represented in FIG. 1 within the kernel 600 as module 612, are stored in a portion of the memory space controlled by the kernel. Each world also has its own task structure, and usually also a data structure for storing the hardware state currently associated with the respective world.
There will usually be different types of worlds: 1) system worlds, which are used for idle worlds, one per CPU, and a helper world that performs tasks that need to be done asynchronously; 2) a console world, which is a special world that runs in the kernel and is associated with the COS 420; and 3) virtual machine worlds.
Worlds preferably run at the most-privileged level (for example, in a system with the Intel x86 architecture, this will be level CPL0), that is, with full rights to invoke any privileged CPU operations. A VMM, which, along with its VM, constitutes a separate world, therefore may use these privileged instructions to allow it to run its associated VM so that it performs just like a corresponding “real” computer, even with respect to privileged operations.
Switching worlds: When the world that is running on a particular CPU (which may be the only one) is preempted by or yields to another world, then a world switch has to occur. A world switch involves saving the context of the current world and restoring the context of the new world such that the new world can begin executing where it left off the last time that it is was running.
The first part of the world switch procedure that is carried out by the kernel is that the current world's state is saved in a data structure that is stored in the kernel's data area. Assuming the common case of an underlying Intel x86 architecture, the state that is saved will typically include: 1) the exception flags register; 2) general purpose registers; 3) segment registers; 4) the instruction pointer (EIP) register; 5) the local descriptor table register; 6) the task register; 7) debug registers; 8) control registers; 9) the interrupt descriptor table register; 10) the global descriptor table register; and 11) the floating point state. Similar state information will need to be saved in systems with other hardware architectures.
After the state of the current world is saved, the state of the new world can be restored. During the process of restoring the new world's state, no exceptions are allowed to take place because, if they did, the state of the new world would be inconsistent upon restoration of the state. The same state that was saved is therefore restored. The last step in the world switch procedure is restoring the new world's code segment and instruction pointer (EIP) registers.
When worlds are initially created, the saved state area for the world is initialized to contain the proper information such that when the system switches to that world, then enough of its state is restored to enable the world to start running. The EIP is therefore set to the address of a special world start function. Thus, when a running world switches to a new world that has never run before, the act of restoring the EIP register will cause the world to begin executing in the world start function.
Switching from and to the COS world requires additional steps, which are described in U.S. patent application Ser. No. 09/877,378, mentioned above. Understanding this process is not necessary for understanding the present invention, however so further discussion is omitted.
Memory management in kernel-based system: The kernel 600 includes a memory management module 616 that manages all machine memory that is not allocated exclusively to the COS 420. When the kernel 600 is loaded, the information about the maximum amount of memory available on the machine is available to the kernel, as well as information about how much of it is being used by the COS. Part of the machine memory is used for the kernel 600 itself and the rest is used for the virtual machine worlds.
Virtual machine worlds use machine memory for two purposes. First, memory is used to back portions of each world's memory region, that is, to store code, data, stacks, etc., in the VMM page table. For example, the code and data for the VMM 300 is backed by machine memory allocated by the kernel 600. Second, memory is used for the guest memory of the virtual machine. The memory management module may include any algorithms for dynamically allocating memory among the different VM's 200.
Interrupt handling in kernel-based system: The kernel 600 preferably also includes an interrupt handler 650 that intercepts and handles interrupts for all devices on the machine. This includes devices such as the mouse that are used exclusively by the COS. Depending on the type of device, the kernel 600 will either handle the interrupt itself or forward the interrupt to the COS.
Device access in kernel-based system: In the preferred embodiment of the invention, the kernel 600 is responsible for providing access to all devices on the physical machine. In addition to other modules that the designer may choose to load into the kernel, the kernel will therefore typically include conventional drivers as needed to control access to devices. Accordingly, FIG. 1 shows within the kernel 600 a module 610 containing loadable kernel modules and drivers.
Kernel file system: In the ESX Server product of VMware, Inc., the kernel 600 includes a fast, simple file system, referred to here as the VM kernel file system (VMKFS), that has proven itself to be particularly efficient for storing virtual disks 240, which typically comprise a small number of large (at least 1 GB) files. By using very large file system blocks, the file system is able to keep the amount of metadata (that is, the data that indicates where data blocks are stored on disk) needed to access all of the data in a file to an arbitrarily small size. This allows all of the metadata to be cached in main memory so that all file system reads and writes can be done without any extra metadata reads or writes.
The VMKFS in ESX Server takes up only a single disk partition. When it is created, it sets aside space for the file system descriptor, space for file descriptor information, including the file name, space for block allocation information, and space for block pointer blocks. The vast majority of the partition's space is used for data blocks, whose size is set when the file system is created. The larger the partition size, the larger the block size should be in order to minimize the size of the metadata.
As mentioned earlier, the main advantage of the VMKFS is that it ensures that all metadata may be cached in high-speed, main system memory. This can be done by using large data block sizes, with small block pointers. Since virtual disks are usually at least one gigabyte in size, using large block sizes on the order of 64 Megabytes will cause virtually no wasted disk space and all metadata for the virtual disk can be cached simultaneously in system memory.
Besides being able to always keep file metadata cached in memory, the other key to high performance file I/O is to reduce the number of metadata updates. Note that the only reason why the VMKFS metadata will need to be updated is if a file is created or destroyed, or if it changes in size. Since these files are used primarily for virtual disks (or, for example, for copy-on-write redo logs), files are not often created or destroyed. Moreover, because virtual disks are usually fixed in size upon creation, the file size of a virtual disk does not usually change. In order to reduce the number of metadata updates on a virtual disk to zero, the system may therefore preallocate all data blocks for virtual disks when the file is created.
Key VM features: For the purposes of understanding the advantages of this invention, the salient points of the discussion above are: (1) each VM 200, . . . , 200b has its own state and is an entity that can operate completely independently of other VMs; (2) the user of a VM, in particular, of an application running on the VM, will usually not be able to notice that the application is running on a VM (which is implemented wholly as software) as opposed to a “real” computer; (3) assuming that different VMs have the same configuration and state, the user will not know and would have no reason to care which VM he is currently using; (4) the entire state (including memory) of any VM is available to its respective VMM, and the entire state of any VM and of any VMM is available to the kernel 600; (5) as a consequence of the above facts, a VM is “relocatable.”
Except for the network 700, the entire multi-VM system shown in FIG. 1 can be implemented in a single physical machine, such as a server. This is illustrated by the single functional boundary 1000. (Of course devices such as keyboards, monitors, etc., will also be included to allow users to access and use the system, possibly via the network 700; these are not shown merely for the sake of simplicity.)
In systems configured as in FIG. 1, the focus is on managing the resources of a single physical machine: Virtual machines are installed on a single hardware platform and the CPU(s), network, memory, and disk resources for that machine are managed by the kernel 600 or similar server software. This represents a limitation that is becoming increasingly undesirable and increasingly unnecessary. For example, if the server 1000 needs to be shut down for maintenance, then the VMs loaded in the server will become inaccessible and therefore useless to those who need them. Moreover, since the VMs must share the single physical memory space 130 and the cycles of the single (or single group of) CPU, these resources are substantially “zero-sum,” such that particularly memory- or processor-intensive tasks may cause noticeably worse performance.
One way to overcome this problem would be to provide multiple servers, each with a set of VMs. Before shutting down one server, its VMs could be powered down or checkpointed and then restored on another server. The problem with this solution is that it still disrupts on-going VM use, and even a delay of ten seconds may be noticeable and irritating to users; delays on the order of minutes will normally be wholly unacceptable.
What is needed is a system that allows greater flexibility in the deployment and use of VMs, but with as little disruption to users as possible. This invention provides such a system, as well as a related method of operation.